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-Abstract- 

In contrast to Computer Science, where the fundamental role of Logic is widely recognized, it 
plays a practically non-existent role in Information Systems curricula. In this paper we argue that 
instead of Logic’s exclusion from the IS curriculum, a significant adaptation of the contents, as 
well as teaching methodologies, is required for an alignment with the needs of IS practitioners. We 
present our vision for such adaptation and report on concrete steps towards its implementation 
in the design and teaching of a course for graduate IS students at the University of Haifa. We 
discuss the course plan and present some data on the students’ feedback on the course. 
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1 Introduction 


The fundamental role of Logic in the Computer Science curriculum is widely recognized. 
The ACM CS undergraduate curriculum guidelines m) explicitly state logic as a mathem¬ 
atical requirement which is directly relevant for the large majority of all CS undergraduates 
(together with elements of set theory and discrete probability). This recommendation is 
implemented in most of the standard CS undergraduate study programs by including in 
the curriculum a course in discrete structures which includes a significant amount of formal 
logic. 

The (academic) field of Information Systems (IS) encompasses two broad areas: (i) 
acquisition, deployment, and management of information technology resources and services, 
and (ii) development and evolution of infrastructure and systems for use in organization 
processes. Thus, as opposed to CS, IS’s primary focus is on an organization’s mission and 
objectives and the application of information technology to further these goals. Yet both IS 
and CS require a common subset of technical knowledge, reflected also in the intersection 
of the respective study programs’ curricula. 

Logic, however, does not appear to be in this intersection - almost none of the IS under¬ 
graduate study programs include such course in their curriculum. The ACM IS curriculum 
guidelines ([T8]), which mention statistics and probability as required core IS topics and 
discrete mathematics as an optional one, but do not refer to logic as relevant: “Even though 
IS professionals do not need the same level of mathematical depth as many other comput¬ 
ing professionals, there are, however, some core elements that are very important for IS 
professionals. To support in-depth analysis of data, IS professionals should have a strong 
background in statistics and probability. For those who are interested in building a strong 
skill set in algorithmic thinking, discrete mathematics is important ." 
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We believe the current state of affairs is suboptimal for several reasons. First of all, 
all the reasons for including logic in the CS curricula still hold in the IS domain: it is 
widely acknowledged that studying logic directly contributes to software development skills, 
confirmed recently also by empirical studies (El)- Secondly, the lack of experience with 
formal notation forms a major cognitive barrier to the adoption of formal methods in the 
industry (ED- This is further reinforced by the fact that because many IS study programs 
tend to be marketed as programs "excluding the hard mathj]] the students come to see the 
lack of mathematical courses as a benefit, and express disappointment when any formal 
notations are integrated in the IS core courses - thus creating a vicious circle. 

Although we tend to agree that a typical IS major may need a less extensive math¬ 
ematical background than a CS major, we believe that rather than excluding logic from 
the IS curriculum, a significant adaptation of the contents that are taught to align with IS 
objectives. Recently more voices are calling for a reconsideration of the traditional logic 
curriculum and its adaptation to the needs of future pracitioners. Several proposals on what 
to teach and how to teach it have been made in the context of CS (on mum). 

In this paper we address these questions in the context of the IS curriculum. We report 
on our experience in designing and teaching the course "Logic and Formal Specification" to 
graduate students at the Information Systems (IS) department at the University of Haifa, 
which is one of the few to include a mandatory course on logic and formal methods in 
its graduate study program. We discuss our view of what should be included in the “IS 
logic toolbox" in order for the students to be able to carry out activities for checking (by 
proof, analysis or testing) that a software system meets specifications and fulfills its intended 
purpose. These tools should at least (i) by providing background on induction and proposi¬ 
tional and first-order logic, and (ii) by providing the ability to read, write and reason about 
formal specifications. We share our insights on how the above can be achieved: (i) excluding 
complex mathematical intricacies, and (ii) providing simple yet software-related examples. 
Concerning the latter, we report on an ongoing work to develop a tool for measuring “simpli¬ 
city" of Z specifications. While the above insights are yet to be empirically validated, some 
indications of the benefits of our approach are reflected in our students’ feedback, which we 
briefly discuss below. 

2 The IS Logic Toolbox 

The main practical objective in teaching logic to IS practitioners is to give them the ability 
to apply formal methods in industry. Application of formal aspects is particularly important 
for software quality control, i.e., activities for checking (by proof, analysis or testing) that a 
software system meets specifications and that it fulfills its intended purpose. 


1 Below are some exemplary quotes from webpages of academic institutions providing both CS and IS 
degrees on the comparison between the two: 

h “As a rule, computer science requires more mathematics and analytical skill than information systems. 
Also, our experience has shown that it is easier to move from being a CS major to an IS major than 
the other way around. Therefore, if you feel reasonably comfortable with the math requirements, 
then you should start out as a computer science major." (Saint Michael’s College) 

h “A major in CS will know a considerable amount of mathematics which will help in technological 
applications...An IS major needs to be aware of what information technology can contribute to an 
organization and how to bring that solution to fruition." (University of Missouri-St. Louis). 

2 Quoting one of our graduate students who was assigned to read a research paper on formal methods: 
“When I see formal definitions, I just want to cry." Notably, she is one of the best students in her class. 
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Due to the density of the IS curricula, currently one cannot afford to have one course on 
pure formal logic and then another on formal methods (this problem is also discussed in |20j 
in the context of CS). Therefore, one must develop some mixture of a introductory formal 
logic together with introduction to formal methods relevant for the IS domain. In what 
follows we briefly survey previous reflections on the content of logic and formal methods 
courses that practitioners really need and their integration into the curricula, and propose 
how to adapt the proposed ideas for the context of IS. 


2.1 Previous Proposals 

Recently there has been an ongoing discussion on whether the traditional logic syllabus for 
CS is relevant for practitioners. Since our main goal in this paper is to extend and adapt 
this discussion to the context of IS, we start by briefly outlining some relevant proposals 
(mostly in the context of CS), the ideas of which are close in spirit to the vision we present 
below. 

In his paper “From Hilbert to a Logic Toolbox” [T3], J. Makowsky questions the suitability 
of the standard logic syllabus to the needs of CS practitioners. He states: “The current 
syllabus is often justified more by the traditional narrative than by the practitioner’s needs." 
He further notes that most classical logic textbooks follow the narrative of the rise and fall 
of Hilbert’s program, emphasizing the following ideas: (i) Logic is needed to resolve the 
paradoxes of set theory; (ii) First-order logic (FOL) is The logic due to its Completeness 
theorem; (iii) The main theorems of FOL are the Completeness and Compactness theorems; 
(iv) The tautologies of FOL are not recursive; (v) One cannot prove consistency within 
rich enough systems. This, according to Makowsky, is not what a CS practitioner needs: 
“The proof of the Completeness Theorem is a waste of time at the expense of teaching more 
the important skills of understanding the manipulation and meaning of formulas." What 
he needs is: (i) understand the meaning and implications of modeling the environment 
as precise mathematical objects and relations; (ii) understand and be able to distinguish 
intended properties of this modeling and side-effects; (iii) be able to discern different level 
of abstraction, and (iv) understand what it means to prove properties of modeled objects. 

In her papers mm j - Wing stresses the importance of integrating formal methods into 
the existing CS curriculum by teaching their common conceptual elements, including state 
machines, invariants, abstraction, composition, induction, specification and verification. She 
states discrete mathematics and mathematical logic as crucial prerequisites. 

The above proposals on what to teach are extremely relevant for IS practitioners. On the 
question of how to teach, the paper “Integrating Formal Methods into Computer Science 
Curricula at a University of Applied Science " (HZ!) of Tavolato and Vogt offers some useful 
insights. It discusses teaching formal methods at universities of applied sciences, where 
there are usually limiting factors which are relevant to the IS context as well: (i) students 
have very limited theoretical background, and (ii) they are strongly focused on the direct 
applicability of what they are taught. In this context the authors stress the importance of 
making the practical applicability of the theory understandable to students, and making use 
of real industry-inspired examples. 

In what follows, we extend and adapt the above proposals to the context of IS, and provide 
our vision on aligning the teaching of logic to the needs of IS practitioners. 
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2.2 Our Vision: Making Logic Relevant for IS 

Logic is a prerequisite for understanding and successfully using formal methods, which in 
their turn can significantly contribute to software quality control. We agree with m that 
the main basic formal conceptual elements that the students need to be familiar with include 
state machines, abstraction, composition, induction, invariants, specification and verifica¬ 
tion. While the students encounter the concepts of state machines, abstraction and com¬ 
position at other IS courses (such as modeling and design), aspects related to working with 
formal specifications are not covered elsewhere. This leads to the following practical needs 
of an IS practitioner: (1) read, write and understand formal specifications, (2) be able to 
formalize informal specifications, (3) analyze specifications and detect sources of incomplete¬ 
ness, inconsistency and complexity, (4) reason about specifications, and (5) check a system 
against a specification. 

Based on the above, adapting and extending the previous proposals to the context of IS, 
we arrive at the following IS logic toolbox: (a) Basic principles for reasoning about sets; (b) 
Induction and invariants; (c) Propositional and first-order logic and their axiomatizations; 
(d) Formal specification and verification. 

As to how to teach logic to IS students, i.e., designing concrete teaching methodologies, 
the following considerations need to be taken into account: 

h Examples from software domains are useful. Although it has been believed for some time 
that studying logic improves software development skills, this common belief has recently 
been empirically validated. In a three-year study in the framework of the Beseme project 
(ED- empirical data on the achievements of two student populations was collected: 
those who studied discrete mathematics (including logic) through examples focused on 
reasoning about software, and those who studied the same subject illustrated with more 
traditional examples. An analysis of the data revealed significant differences in the 
programming effectiveness of these two populations in favor of the former. As pointed 
out by ED software related examples are also useful for increasing the motivation of 
students, who can see the applications of the studied material in the domain of their 
interest. 

h Cognitive difficulties should not be ignored. Empirical studies show that the use of formal 
methods poses objective difficulties for practitioners mm)- They are also hypothesized 
to be a major hindering factor for the acceptance of formal methods in industry (EU). 
Although the cognitive processes of students when studying logic and formal methods are 
not well understood, they should not be ignored (E])- Numerous studies in the educa¬ 
tion community addressed the gap between the students’ intuition and formal thinking 
in mathematics (see, e.g., [7]). Implementing similar ideas in the domain of teaching 
logic and formal methods may help deal with these barriers. 
h Intricate complexities are not always needed. Exposing the students to full intricate 
complexities of mathematical logic (such as a full proof of the completeness theorem, 
or dealing with variables not free for substitution) has the potential to confuse novices 
struggling to understand new ideas. However, most of the practitioners will not en¬ 
counter them in industry. This is in line the research agenda of indirect application 
of formal methods (ED, calling for hiding the intricate complexities behind automatic 
tools with intuitive user interface. The benefits of hiding logical complexity behind the 
more intuitive interface of functional programming are also mentioned in ra¬ 
in view of the above considerations, the basic principles in the design of the course 
described below have been (i) use mainly examples from software domains, (ii) use com¬ 
prehensible examples, and (iii) introduce the logical concepts at a basic level. The issue of 
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comprehensibility also led to our ongoing work of automatically measuring comprehensibility 
of Z specifications, which we briefly describe below. 

3 Teaching Logic at the IS Department of the University of Haifa 

In this section we demonstrate how the vision presented in Section [2.2| has been implemented 
in our design of the course “Logic and Formal Specification”. The course has been taught 
at the IS department at the University of Haifa for several years by both of the author^ 
The course is a mandatory course for graduate students, and its length is one semester, 4 
hours per week. 


3.1 Course Description 

Below we provide a short description of the course’s main topics, which are divided into two 

main parts: 

Part I: Introduction to Logic 

h Informal laws of mathematical reasoning 

Our starting point is the place where the students left off in a discrete mathematics 
course: with basic set-theoretical concepts. However, our primary focus is not on un¬ 
derstanding the concepts themselves, but on reasoning about them by applying informal 
logical laws. Accordingly, the students are asked to provide proofs of basic claims, ex¬ 
plaining which laws were used at each stage. The presentation of the informal laws and 
other proof tips is adapted from [T2]. The informal laws become explicit at the object 
level when classical propositional and first-order logic are introduced to the students 
(E.g., the law for proving general statements can be captured by the rule inferring V xip 
from and the law for proving conditional statements is captured by the deduction 

theorem.) 

h Induction: mathematical, structural and computational induction. 

Induction is in the heart of several formal concepts relevant for verification and validation 
of software: fixed point constructions, model checking, program analysis and many more. 
Therefore a special emphasis is put on the topic throughout the course, highlighting its 
various manifestations, e.g. proving syntactic properties of logical formulas, proving the 
deduction theorem, proving invariants with respect to a Z specification. Software-related 
examples are adapted from Chapter 2 of (ED- 

h Classical Propositional and First-Order Logic: syntax and semantics, satisfiability and 
validity, Hilbert-style axiomatization, formalization of natural language sentences. 

For this part of the course we mostly adapt parts of the standard presentation of most 
mathematical logic textbooks. We make a special emphasis on formalization of nat¬ 
ural language specifications and induction at the expense of omitting the proofs of the 
Completeness and Compactness theorems (in line with the recommendation of ns). 


3 Perhaps it is important to mention here the authors’ relevant background. The first author is an 
associate professor at the Information Systems Department at the University of Haifa with active 
research interests in applied logic. The second author is the manager of the Software Performance and 
Quality research group at the IBM Haifa Research Laboratory, and a member of the IBM corporate 
Board of Software Quality. Both of the authors have several years of experience in teaching logic and 
formal methods to various audiences of students. 
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Survey of non-classical temporal logic, modal logic, many-valued logic, fuzzy 

logic, non-monotonic logic, paraconsistent logic. 

Part II: Introduction to Formal Specification 

This part of the course builds up on the knowledge obtained at the previous part. The 
final aim is for the students to be able to understand and write formal specifications using 
the Z notation. For this we have adapted the material from the textbook m, covering the 
basic aspects of Z: types, schemas and reasoning about Z specifications. However, staying 
faithful to our vision oulined above, we have developed our own set of examples, which are 
(i) "simple" and (ii) related to software domains. In what follows we shortly discuss what 
we mean by "simple" and how "simplicity" can be measured. 

Measuring comprehensibility of Z specifications 

The notion of simplicity (item (i) above) is not well understood. Comprehensibility (or 
understandability) of specifications is usually thought of as the degree to which information 
contained in a specification is understandable to the reader, and this is a well-studied topic 
in software engineering (see, e.g., [B] for a survey). However, we are aware of only a few 
works on Z specifications mm), all of which on the structural dimension. We believe, 
however, that simplicity is a key to comprehensibility of specifications, at least at the stage 
of learning the topic. Our attempt to quantitatively measure "simplicity has led to our 
ongoing project of developing automatic tools for this purpose. Our current hypothesis is 
that the nesting of definitions is and shortening notations by introducing additional symbols 
decrease the understandability of specifications. We are currently developing a too|^] for 
measuring "simplicity" of specifications. Using this tool, we plan to empirically check our 
hypothesis, as well as to consider other comprehensibility dimensions. 

Students’ Acceptance 

The course has only been taught in its current form for five years, so making decisive 
conclusions about its effectiveness is perhaps premature. However, an important dimension 
in evaluating such effectiveness is the students’ acceptance and reaction. To gain a better 
understanding of these factors, the first author has undertaken a preliminary qualitative 
study using a questionnaire filled by twenty three students who took the course in 2013- 
2014. 

It should be noted that the limiting factors typical of our target audience are in many 
aspects similar to those described in [I7J. The first is lack of mathematical background: the 
undergraduate IS study program at the University of Haifa does not include a course in 
logic, and the majority of students have only a background in discrete mathematics, where 
they are taught very basic concepts of set theory. The second limiting factor is their lack 
of motivation: the majority of the students return to graduate school several years after 
receiving their B.A, while working full-time. They typically expect the topics to be directly 


4 This part of the course is implemented by assigning each of the students a short presentation on a 
non-classical logic or its applications of his choice. While the importance of temporal logic in this 
context is perhaps the most obvious one due to its well-known applications in verification, also other 
non-classical logics have IS-relevant applications. Our goal here is to increase the awareness of the 
students to the immense variety of logics outside the realm of classical logics, as well as engage them 
more actively in the course. Several students have reported that exploring new logics on their own was 
the part they enjoyed the most in the course. 

5 The tool is based on the open-source Java framework Community Z tools ( 0 ). 
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relevant to their IS practice, and usually exhibit difficulty in coping with the dense and 
abstract material taught in the course. In light of these factors, we were expecting some 
of the students to claim, basically, that the course was too hard without being helpful for 
their future as IS practitioners. However, only one student out of 23 felt the course was not 
useful for his practice. A full analysis of the data obtained from students is out of the scope 
of this paper. However, some aspects highlighted by the data were that (i) the majority of 
students felt the course has improved their analytical thinking abilitie^j (ii) the majority 
of students felt the part related to formal specification is relevant for their IS practice^ and 
(iii) some students felt the course has directly improved their daily IS practic^] 

4 Summary and Future Research 

There has recently been a discourse on the relevance of traditional logic courses to future 
computer science practitioners. Jeannette Wing writes in m .we still face the educa¬ 
tional challenge of teaching mathematical foundations like logic and discrete mathematics 
to practicing or aspiring software engineers. We need to go beyond giving the traditional 
courses and think about who the target students are." This paper discusses these issues for 
the target population of IS students, for whom the lack of direct relevance of the traditional 
logic courses seems to have led to their exclusion from the curriculum. We believe logic is 
central to IS objectives, as it is the key to applying formal methods in specification, veri¬ 
fication and validation of information systems. Ideally, we need more empirical evidence in 
the spirit of the Beseme project (HD that such courses are useful for IS practitioners. In 
addidion, there is a need for a wider discussion on what logical background is needed for 
Information Systems practitioners and how it should be taught. In a contribution to such 
discussion, we have reported on our insights from teaching the “Logic and Formal Specific¬ 
ation" course to graduate IS students. Like previous authors report in the context of CS, 
we have seen that using software-related and comprehensible examples, as well as simpli¬ 
fication of logical intricacies contributes to achieving the courses’ objectives. From a more 
practical perspective, a future direction is an empirical investigation of how to make formal 
specification more understandable for students. This question is particularly interesting due 
to its direct relation to the more general topic of comprehensibility of specifications. In this 
context we plan to extend and refine our tool for automatic analysis of Z specifications and 
carry out an empirical evaluation. From the angle of education, strategies for an efficient 
integration of logic and formal methods into the IS curricula are required (along the lines 
of glUnj), as well as an investigation of the ways to bridge intuitive and analytical thinking 
processes in logic and formal methods (along the lines of [7]). In this context we would also 
like to point out that a textbook with an IS-orientation would be a welcome addition to the 
large existing variety of CS-orientecl books. 
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